Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache finalised attributes to avoid conversion overhead every usage #282

Merged
merged 2 commits into from
Oct 21, 2024

Conversation

peppy
Copy link
Member

@peppy peppy commented Oct 18, 2024

No description provided.

Comment on lines +100 to +112
try
{
if (dbAttribs.Length == 0)
return difficultyAttributes;

return difficultyAttributes;
difficultyAttributes = LegacyRulesetHelper.CreateDifficultyAttributes(ruleset.RulesetInfo.OnlineID);
difficultyAttributes.FromDatabaseAttributes(dbAttribs.ToDictionary(a => (int)a.attrib_id, a => (double)a.value), beatmap);
return difficultyAttributes;
}
finally
{
attributeCache[key] = difficultyAttributes;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe all of this works but it's intricate enough to be pushing my limits of how much subtlety I'm willing to accept in code, what with all of the juggling of difficultyAttributes, implicit null returns of TryGetValue(), and finally used to coalesce return paths in order to populate attributeCache...

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, this is the standard way I'd write any caching code (I believe it's done this was elsewhere) but I'm neutral to approaching it differently. Would be be more understandable if the early return did the null-caching inline?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The general pattern is standard yes, I'm more talking about the mechanics here.

Would be be more understandable if the early return did the null-caching inline?

To a degree, but it would also make it mechanically uglier, so I decided I would just put up with this as is.

Copy link
Contributor

@smoogipoo smoogipoo Oct 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One thing to keep in mind is that this will cache attributes even if they fail, and then they will pass as if nothing went wrong the next time around. There's two places that can fail - either the attributes are not present in the DB which I can't immediately think of a situation in which it should be allowed (and it previously returned null too), or the deserialisation fails which is always a bad sign.

Exercise is left up to the reader to determine what this means for scores computed using the "actually failed but cached" attribs.

@bdach bdach merged commit 6bfa8e5 into ppy:master Oct 21, 2024
3 checks passed
@peppy peppy deleted the cache-finalised-attribs branch November 22, 2024 06:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants